OpenEdge Getting Started:<br />Application and Integration Services WSA configuration and Web service deployment tools

Figure 6–6 shows OpenEdge tools used to configure and manage a WSA and to deploy and manage Web services.

The WSA is the central component for all aspects of Web service deployment, configuration, and run-time management. As the figure shows, you can manage the entire WSA and Web service configuration using the Progress Explorer framework, which accesses the WSA as an OpenEdge server to which Web services are deployed. For more information on the Progress Explorer framework and how to work with OpenEdge servers, see OpenEdge Getting Started: Installation and Configuration .

On the Web server, the WSA is installed as a single JSE Web application for which you must create instances to do meaningful work. The dashed arrows in the figure indicate that each WSA instance is created from its definition in the ubroker.properties file, which is read by WSA to create the instance. When you deploy a Web service, you deploy it to a WSA instance, which defines the root Universal Resource Locator (URL) used to access the Web service and handles all of its client communications. Each WSA instance thus manages its own set of deployed Web services.

The WSA comes installed with a default WSA instance, wsa1, but no default deployed Web services. You can deploy sample Web services provided with the OpenEdge installation. For more information on these samples, see OpenEdge Development: Web Services .

To begin using the WSA, you must configure it using the Progress Explorer or the WSAMAN command-line utility. (This assumes you already installed and configured the JSE to recognize the WSA as a Web application. For more information, see the OpenEdge Application Server: Administration .) Similar to other OpenEdge servers, you can create one or more uniquely named WSA instances and set properties for each one in the WSA’s ubroker.properties file.

For each new WSA instance that you create, two files are created, default.props and DeployedServices.ds. The default.props file contains the default values to set for the run-time properties of each Web service that you deploy to the instance, and the DeployedServices.ds file contains the identity and deployment information of each Web service that is already deployed to that instance.

Once you have created and started up a WSA instance, you can deploy a Web service to it using Progress Explorer or the wsaman utility. Input for the deployment includes the WSM file generated for the Web service by ProxyGen (WorldWeather.wsm, in Figure 6–6) and additional deployment information that you specify, such as a friendly name (FriendlyName) for the Web service. The deployment output includes three files created in the context of the WSA instance:

FriendlyName.props — WorldWeather.props in Figure 6–6, the Web service properties file containing the Web service run-time property values, initially set to the values in the WSA instance’s default.props file.

FriendlyName.wsdl — WorldWeather.wsdl in Figure 6–6, the WSDL file that contains the Web service definition. This definition describes to a Web service client how to code and decode SOAP messages for the Web service, and specifies the interface for operations that the client must use to send these messages.

FriendlyName.wsad — WorldWeather.wsad in Figure 6–6, the Web services application descriptor (WSAD) file that defines the Web service to the WSA instance. This file describes the Web service to the WSA so that it can code and decode client SOAP messages for the Web service, and specifies how to access the AppServer application that executes SOAP requests.

Thus, the figure shows the WorldWeather Web service deployed to the WSA instance, wsa1, and also another WSA instance, wsa2, that has no Web services deployed to it.